<html>
<head><meta charset="utf-8"><title>NaNs during CTFE · t-compiler/const-eval · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/index.html">t-compiler/const-eval</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html">NaNs during CTFE</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="231552895"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231552895" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231552895">(Mar 23 2021 at 22:19)</a>:</h4>
<p><span class="user-mention" data-user-id="120791">@RalfJ</span> re: NaNs, is it possible to just issue a compilation failure on encountering certain values (like NaN) in CTFE?</p>



<a name="231556637"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231556637" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231556637">(Mar 23 2021 at 22:55)</a>:</h4>
<p>yeah, that's something i've talked about in DM with ralf before (and know from my meager patches to miri). It should be completely possible, however note that it's a breaking change. Even the stdlib produces NaNs: <a href="https://doc.rust-lang.org/src/core/num/f64.rs.html#365">https://doc.rust-lang.org/src/core/num/f64.rs.html#365</a></p>



<a name="231566737"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231566737" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231566737">(Mar 24 2021 at 00:51)</a>:</h4>
<p><span class="user-mention" data-user-id="209168">@Thom Chiovoloni</span> do you think we could do it as "no NAN inputs, yes NAN outputs"?</p>



<a name="231567844"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231567844" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231567844">(Mar 24 2021 at 01:06)</a>:</h4>
<p>That was actually my suggestion in the past. I think it would still break backwards compat though, since </p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">FOO</span>: <span class="kt">f64</span> <span class="o">=</span><span class="w"> </span><span class="kt">f64</span>::<span class="n">NAN</span><span class="w"> </span><span class="o">*</span><span class="w"> </span><span class="mf">2.0</span><span class="p">;</span><span class="w"></span>
</code></pre></div>
<p>is totally valid today.</p>
<p>That said, we could forbid it in <code>const fn</code>, which doesnt allow any float operations atm.</p>



<a name="231574258"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231574258" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231574258">(Mar 24 2021 at 02:39)</a>:</h4>
<p>well, we know that should produce a NAN, just which NAN is unknown :^)</p>



<a name="231686051"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231686051" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231686051">(Mar 24 2021 at 18:33)</a>:</h4>
<p>indeed this is not very hard, we'd have to add NaN checks <a href="https://github.com/rust-lang/rust/blob/f5fe425c925ef36d5f4c18cfa44173fc42de31b8/compiler/rustc_mir/src/interpret/operator.rs#L297">around here</a></p>



<a name="231686246"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231686246" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231686246">(Mar 24 2021 at 18:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/const.20eval.20of.20SIMD.20ops/near/231566737">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> do you think we could do it as "no NAN inputs, yes NAN outputs"?</p>
</blockquote>
<p>now that is surprising, I would have expected the opposite ;) NaN outputs are the critical ones as we don't know which NaN we should produce, right?</p>



<a name="231789882"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/231789882" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#231789882">(Mar 25 2021 at 12:16)</a>:</h4>
<p><span class="user-mention silent" data-user-id="209168">Thom Chiovoloni</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/231567844">said</a>:</p>
<blockquote>
<p>That was actually my suggestion in the past. I think it would still break backwards compat though, since </p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">const</span><span class="w"> </span><span class="n">FOO</span>: <span class="kt">f64</span> <span class="o">=</span><span class="w"> </span><span class="kt">f64</span>::<span class="n">NAN</span><span class="w"> </span><span class="o">*</span><span class="w"> </span><span class="mf">2.0</span><span class="p">;</span><span class="w"></span>
</code></pre></div>
<p>is totally valid today.</p>
<p>That said, we could forbid it in <code>const fn</code>, which doesnt allow any float operations atm.</p>
</blockquote>
<p>I don't think we should do that -- I don't like the idea of making the <em>dynamic semantics of CTFE</em> depend on whether things happen in a <code>const</code> vs <code>const fn</code>.<br>
We do that for the static semantics, i.e. for const-validity checks, but those are basically temporary hacks that were put in place so <code>const fn</code> could be stabilized more quickly. They should all eventually disappear.</p>



<a name="232737242"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232737242" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232737242">(Apr 01 2021 at 10:49)</a>:</h4>
<p>Instead of producing a NaN bit pattern, we could also produce a <code>Scalar::Ptr(fake_alloc_id)</code>. Essentially we'd encode the meaning of one specific alloc id to mean <code>NaN</code>. This way we could ensure that the bits are never inspected, unless they are in the final value of a constant and are used in codegen to produce a LLVM constant.</p>



<a name="232920960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232920960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232920960">(Apr 02 2021 at 16:40)</a>:</h4>
<p>oh wow...</p>



<a name="232921033"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232921033" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232921033">(Apr 02 2021 at 16:41)</a>:</h4>
<p>this could be observable though if someone transmutes a NaN <code>f64</code> to <code>&amp;()</code> and that suddenly fails to be UB</p>



<a name="232921088"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232921088" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232921088">(Apr 02 2021 at 16:41)</a>:</h4>
<p>hm or maybe that's okay actually, we can allow ints at <code>&amp;()</code>. we'd have to make the alignment of that fake allocation <code>1</code>, but other than that....</p>



<a name="232921127"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232921127" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232921127">(Apr 02 2021 at 16:42)</a>:</h4>
<p><span class="user-mention" data-user-id="124288">@oli</span>  am I taking an april 1st proposal too seriously or are you actually considering this?^^</p>



<a name="232921229"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232921229" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232921229">(Apr 02 2021 at 16:42)</a>:</h4>
<p>I <em>want</em> to find something that's wrong with this since it just seems too crazy but so far I haven't found anything worse than "this is quite the hack"...</p>



<a name="232924163"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232924163" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232924163">(Apr 02 2021 at 17:03)</a>:</h4>
<blockquote>
<p><span class="user-mention silent" data-user-id="124288">oli</span>  am I taking an april 1st proposal too seriously or are you actually considering this?^^</p>
</blockquote>
<p>This was meant in full seriousness modulo me not knowing if there are problems with it</p>



<a name="232924547"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232924547" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232924547">(Apr 02 2021 at 17:06)</a>:</h4>
<blockquote>
<p>this could be observable though if someone transmutes a NaN <code>f64</code> to <code>&amp;()</code> and that suddenly fails to be UB</p>
</blockquote>
<p>Well, my idea was to not even have a backing allocation, so essentially just like function pointers, which you also shouldn't put where ppl will deref them at another type</p>



<a name="232924606"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232924606" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232924606">(Apr 02 2021 at 17:06)</a>:</h4>
<p>Idk what we do right now if you transmute a function pointer to <code>&amp;()</code>, but whatever it is, nans should do the same</p>



<a name="232924801"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232924801" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232924801">(Apr 02 2021 at 17:08)</a>:</h4>
<p>well, a function pointer at least conceptually is an actual address in memory</p>



<a name="232924840"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232924840" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232924840">(Apr 02 2021 at 17:08)</a>:</h4>
<p>a NaN isn't by any stretch of imagination</p>



<a name="232925046"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232925046" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232925046">(Apr 02 2021 at 17:10)</a>:</h4>
<p>but the only way I can think of that this would become problematic is comparison... we'd never make NaNs guarateed_eq or guaranteed_ne with anything, so that would also be okay... hm</p>



<a name="232926019"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232926019" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232926019">(Apr 02 2021 at 17:17)</a>:</h4>
<blockquote>
<p>well, a function pointer at least conceptually is an actual address in memory</p>
</blockquote>
<p>Doesn't that imply that functions and data are stored in the same address space? Couldn't it be defined as this not being the case in CTFE?</p>



<a name="232927519"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232927519" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232927519">(Apr 02 2021 at 17:28)</a>:</h4>
<p>Rust/CTFE doesn't really have a notion of there being different address spaces</p>



<a name="232927690"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232927690" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232927690">(Apr 02 2021 at 17:29)</a>:</h4>
<p>but AFAIK our CTFE ptr comparison code is correct even when code and data addresses can seemingly overlap due to actually being in different address spaces</p>



<a name="232927931"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232927931" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232927931">(Apr 02 2021 at 17:31)</a>:</h4>
<p>well we do assume that functions never live at address 0</p>



<a name="232927962"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/232927962" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#232927962">(Apr 02 2021 at 17:31)</a>:</h4>
<p>but that's wired pretty deep into Rust, <code>fn()</code> has a validity invariant of being nonnull</p>



<a name="236083593"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/236083593" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#236083593">(Apr 25 2021 at 18:17)</a>:</h4>
<p>Ahhh catching up... oli's idea sounds pretty good to me at first glance. So basically when a NaN is produced, it becomes opaque to the rest of CTFE?</p>



<a name="236133132"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/236133132" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#236133132">(Apr 26 2021 at 07:48)</a>:</h4>
<p>yes, and only during codegen is it transformed into an actual value, which may not be entirely the same thing that llvm const propagation may have produced for the same operation, but at least nothing before that made a decision depending on that value</p>



<a name="236135474"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/236135474" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> tm <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#236135474">(Apr 26 2021 at 08:09)</a>:</h4>
<p>Part of this discussion reminds me of non-determinism that arises with statics holding function pointers. The pointer value stored in one static can be read and stored in another static, but they might codegen to a different value.</p>



<a name="236135614"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/236135614" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#236135614">(Apr 26 2021 at 08:11)</a>:</h4>
<p><span class="user-mention silent" data-user-id="352985">tm</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/236135474">said</a>:</p>
<blockquote>
<p>Part of this discussion reminds me of non-determinism that arises with statics holding function pointers. The pointer value stored in one static can be read and stored in another static, but they might codegen to a different value.</p>
</blockquote>
<p>that's a bug that we should just fix</p>



<a name="241629835"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/241629835" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#241629835">(Jun 05 2021 at 10:47)</a>:</h4>
<p>More concretely, it is this bug: <a href="https://github.com/rust-lang/rust/issues/79738">https://github.com/rust-lang/rust/issues/79738</a></p>



<a name="241629844"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/241629844" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#241629844">(Jun 05 2021 at 10:47)</a>:</h4>
<p>Regarding the NaN question, also see <a href="https://github.com/rust-lang/rust/issues/77745#issuecomment-855220483">this problem</a>... unless we find a <em>deterministic</em> spec for NaN behavior, it is still inherently the case that allowing NaNs to arise inside <code>const fn</code> will lead to non-deterministic <code>const fn</code>.</p>



<a name="241629892"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/241629892" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#241629892">(Jun 05 2021 at 10:48)</a>:</h4>
<p>We can shield const-eval itself from the consequences of that non-determinisim, but it would be observable at run-time</p>



<a name="241629898"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/241629898" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#241629898">(Jun 05 2021 at 10:48)</a>:</h4>
<p>if we are okay with that is a "value" question that is hard to judge on technical grounds, I think</p>



<a name="242958461"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242958461" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242958461">(Jun 16 2021 at 23:58)</a>:</h4>
<p>hmm.<br>
is it possible to make certain things <code>unsafe</code> only in const, lol.</p>



<a name="242963164"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242963164" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Lokathor <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242963164">(Jun 17 2021 at 01:17)</a>:</h4>
<p>i don't think that declaring it unsafe actually fixes the const / runtime inconsistency</p>



<a name="242964582"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242964582" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242964582">(Jun 17 2021 at 01:53)</a>:</h4>
<blockquote>
<p>deterministic spec for NaN behavior</p>
</blockquote>
<p>in practice it's not that bad to implement the correct behavior. each target has their own spec, but most are pretty close. the issue is:</p>
<ol>
<li>fixing it requires fixing APFloat.</li>
<li>fixing APFloat requires fixing it in LLVM before we can fix it in rustc</li>
<li>fixing it in llvm likely requires a bunch of bickering on mailing lists, and then changing a bunch of c++ code.</li>
</ol>
<p>actually, in practice I think well over 90% of our issues would be solved by generating the correct default nan for the target (the nan generated for operations that produce a nan when no nan was present in the input), which might be doable on our own</p>



<a name="242964648"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242964648" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242964648">(Jun 17 2021 at 01:54)</a>:</h4>
<p>you can get a good idea of the complexity here by looking in qemu's source <a href="https://github.com/qemu/qemu/tree/master/fpu">https://github.com/qemu/qemu/tree/master/fpu</a>. the target-dependent parts are really not that bad in practice.</p>



<a name="242966338"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242966338" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242966338">(Jun 17 2021 at 02:35)</a>:</h4>
<p>heheh.</p>



<a name="242966352"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242966352" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242966352">(Jun 17 2021 at 02:35)</a>:</h4>
<p>hmm.</p>



<a name="242970262"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242970262" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242970262">(Jun 17 2021 at 04:01)</a>:</h4>
<p>I have the encoding for the default NaNs of a pile of arches in <a href="https://docs.rs/simple-soft-float/0.1.0/src/simple_soft_float/lib.rs.html#1167"><code>simple-soft-float</code></a></p>



<a name="242975350"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242975350" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242975350">(Jun 17 2021 at 05:43)</a>:</h4>
<p>if we could do that, then we could probably also forbid operations that take nan inputs as well. i think the only time i've seen people generate nans at compile time intentionally it was in an effort to get just <em>some</em> nan (and presumably they either dont care which or they want the default one — which we havent been giving them)</p>



<a name="242999815"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/242999815" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#242999815">(Jun 17 2021 at 10:44)</a>:</h4>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/242958461">said</a>:</p>
<blockquote>
<p>hmm.<br>
is it possible to make certain things <code>unsafe</code> only in const, lol.</p>
</blockquote>
<p>yes, pointer to int casts are already unsafe only in const</p>



<a name="243052086"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243052086" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243052086">(Jun 17 2021 at 17:16)</a>:</h4>
<p>I think we should allow NaNs as inputs and outputs, just disallowing non-default NaNs. <code>f32::NAN</code> and <code>f64::NAN</code> <em>should</em> be the default NaN values (I didn't check, but if we're using the wrong value it seems like a design flaw)</p>



<a name="243052793"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243052793" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243052793">(Jun 17 2021 at 17:21)</a>:</h4>
<p>For ops like negation, abs, and copysign, where it's just manipulating the sign bit and leaves other bits unmodified, all NaNs should be allowed as inputs/outputs, assuming we allow something arbitrary to be stored in a <code>f32</code> we're just passing around like <code>f32::from_bits(0xFFF47287)</code>. For architectures like RISC-V, where all non-sign-manipulation arithmetic operations return canonical NaNs no matter what, we could relax those rules somewhat, if we didn't care as much about cross-arch consistancy.</p>



<a name="243053601"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243053601" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243053601">(Jun 17 2021 at 17:27)</a>:</h4>
<p>Allowing default-only NaNs as input/outputs at compile time makes FP have waay fewer compile-time gotchas than disallowing NaNs completely, NaNs do have a purpose...</p>



<a name="243053771"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243053771" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243053771">(Jun 17 2021 at 17:29)</a>:</h4>
<p>encountering a non-default NaN is quite rare imho.</p>



<a name="243074285"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243074285" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243074285">(Jun 17 2021 at 19:50)</a>:</h4>
<p>ah, good point, if all input nans are default nans, then all output nans will be default nans as well (on everything i'm aware of, at least). I hadn't thought about that.</p>



<a name="243074329"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243074329" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243074329">(Jun 17 2021 at 19:50)</a>:</h4>
<p>and yes, f32/f64 are not the default nans for many platforms</p>



<a name="243074604"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243074604" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243074604">(Jun 17 2021 at 19:52)</a>:</h4>
<p>I think the gotcha here <em>is</em> stuff like copysign/neg which can produce a non-default nan that will expose the fact that we don't follow all the rules properly</p>



<a name="243076948"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243076948" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243076948">(Jun 17 2021 at 20:08)</a>:</h4>
<p>could we just adopt WebAssembly's stance and say something like the NaN that is selected for each FP op may depend on optimization, compiler host arch, target arch, input arguments, cpu compiler is running on, cpu generated program runs on, etc?</p>



<a name="243077130"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243077130" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243077130">(Jun 17 2021 at 20:10)</a>:</h4>
<p>currently llvm doesn't seem to do much better than that anyway</p>



<a name="243077493"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243077493" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243077493">(Jun 17 2021 at 20:12)</a>:</h4>
<p>for const eval, we could just arbitrarily decide to replace all NaNs in arithmetic results with <code>f32::NAN</code>, except for ops like neg and copysign that are just bit manipulation.</p>



<a name="243079097"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243079097" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243079097">(Jun 17 2021 at 20:24)</a>:</h4>
<p>that's an option, but it means nan fundamentally are nondeterministic in rust, which, personally, i think wouldn't be a great outcome</p>



<a name="243080467"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243080467" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243080467">(Jun 17 2021 at 20:33)</a>:</h4>
<p>Note that if we switch const-eval to use the arch-specific default NaN, then <code>f32::NAN</code> also changes, since it's defined as <code>0.0 / 0.0</code></p>



<a name="243080704"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243080704" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243080704">(Jun 17 2021 at 20:35)</a>:</h4>
<p>right, that's what i was saying</p>



<a name="243236088"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243236088" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243236088">(Jun 19 2021 at 07:55)</a>:</h4>
<p><span class="user-mention silent" data-user-id="124288">oli</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/242999815">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/242958461">said</a>:</p>
<blockquote>
<p>hmm.<br>
is it possible to make certain things <code>unsafe</code> only in const, lol.</p>
</blockquote>
<p>yes, pointer to int casts are already unsafe only in const</p>
</blockquote>
<p>aren't they entirely forbidden in <code>const</code>? they should be...</p>



<a name="243236158"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243236158" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243236158">(Jun 19 2021 at 07:57)</a>:</h4>
<p>the problem with any proposal that rejects certain nans or nan-related operations during CTFE is that it will introduce "unconst" operations: operations that people think are fine and safe, and that <em>are</em> completely safe at runtime, but that will lead to errors when being done during CTFE.</p>



<a name="243236362"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243236362" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243236362">(Jun 19 2021 at 08:03)</a>:</h4>
<p>probably the least intrusive one is the proposal that makes NaN bit patterns unobservable during CTFE -- <code>f{32,64}::to_bits</code> still seems to be const-unstable (but rustdoc rendering for this is confusing).<br>
for consts with NaNs in their final result, we'd presumably use a target default NaN, or abort compilation (the latter being a breaking change).<br>
The main problem this proposal does not solve is that if the target has non-deterministic NaNs (which AFAIK real hardware does not, but wasm does and who knows that LLVM optimizations might lead to), then this would let one write non-deterministic <code>const fn</code>.<br>
the more often this comes up, the less hopeful I am that we can truly use <code>const fn</code> as a substitute for "pure"...</p>



<a name="243246039"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243246039" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243246039">(Jun 19 2021 at 11:53)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/243236088">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="124288">oli</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/242999815">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="281757">Jubilee</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/242958461">said</a>:</p>
<blockquote>
<p>hmm.<br>
is it possible to make certain things <code>unsafe</code> only in const, lol.</p>
</blockquote>
<p>yes, pointer to int casts are already unsafe only in const</p>
</blockquote>
<p>aren't they entirely forbidden in <code>const</code>? they should be...</p>
</blockquote>
<p>the are behind const_raw_ptr_to_usize_cast with which they are unsafe, but possible</p>



<a name="243246108"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243246108" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> oli <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243246108">(Jun 19 2021 at 11:55)</a>:</h4>
<p><span class="user-mention silent" data-user-id="120791">RalfJ</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/243236362">said</a>:</p>
<blockquote>
<p>probably the least intrusive one is the proposal that makes NaN bit patterns unobservable during CTFE -- <code>f{32,64}::to_bits</code> still seems to be const-unstable (but rustdoc rendering for this is confusing).<br>
for consts with NaNs in their final result, we'd presumably use a target default NaN, or abort compilation (the latter being a breaking change).<br>
The main problem this proposal does not solve is that if the target has non-deterministic NaNs (which AFAIK real hardware does not, but wasm does and who knows that LLVM optimizations might lead to), then this would let one write non-deterministic <code>const fn</code>.<br>
the more often this comes up, the less hopeful I am that we can truly use <code>const fn</code> as a substitute for "pure"...</p>
</blockquote>
<p>we could "just" keep forbidding floats forever and require users to use a soft float library</p>



<a name="243248509"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243248509" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243248509">(Jun 19 2021 at 12:49)</a>:</h4>
<blockquote>
<p>the are behind const_raw_ptr_to_usize_cast with which they are unsafe, but possible</p>
</blockquote>
<p>okay, unstably.<br>
I am honestly not sure if we ever want to stbailize this, or if we should just remove that feature... but that is a different discussion.</p>



<a name="243266686"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243266686" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243266686">(Jun 19 2021 at 20:09)</a>:</h4>
<p>just make floating point <code>unsafe</code> /s</p>



<a name="243267517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243267517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243267517">(Jun 19 2021 at 20:29)</a>:</h4>
<p>actually kinda seriously: why don't we mark all the floating point operations that allow inspecting NAN bits as <code>const unsafe</code>?</p>



<a name="243278523"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243278523" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> matt1992 <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243278523">(Jun 20 2021 at 01:05)</a>:</h4>
<p>There isn't currently a way to say "this function is only unsafe to call in const contexts"<br>
<code>const unsafe</code> means unsafe to call at runtime too</p>



<a name="243280502"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243280502" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243280502">(Jun 20 2021 at 02:02)</a>:</h4>
<p>hmm.</p>



<a name="243280517"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243280517" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Thom Chiovoloni <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243280517">(Jun 20 2021 at 02:03)</a>:</h4>
<p>i dont think it solves the issue anyway, since you could just wait until runtime to inspect the bits</p>



<a name="243280569"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/243280569" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#243280569">(Jun 20 2021 at 02:04)</a>:</h4>
<p>right.</p>



<a name="244975896"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/244975896" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#244975896">(Jul 05 2021 at 21:35)</a>:</h4>
<blockquote>
<p>And this means that whatever scheme we come up with for handling NaNs during CTFE, must also work in promoteds. :/</p>
</blockquote>
<p>What does this mean?</p>



<a name="245140284"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/245140284" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#245140284">(Jul 07 2021 at 07:37)</a>:</h4>
<p>Well, that's a good question.<br>
It certainly means we cannot make anything error that could be done in safe code with primitive float ops -- like, all proposals that suggest to error when a float op has a NaN input are pretty much out</p>



<a name="245140385"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/245140385" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#245140385">(Jul 07 2021 at 07:38)</a>:</h4>
<p>I think erroring on <code>to_bits</code> of floats is still on the table since <code>to_bits</code> is not subject to promotion (outside of <code>const</code>/<code>static</code> items and those are already weird anyway)</p>



<a name="245151702"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/245151702" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jacob Lifshay <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#245151702">(Jul 07 2021 at 09:18)</a>:</h4>
<p>hmm, seems like bypassing <code>to_bits</code> can be done by using <code>transmute</code> or <code>union</code>, would those errors also occur in those cases?</p>



<a name="245395015"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/245395015" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Jubilee <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#245395015">(Jul 09 2021 at 02:56)</a>:</h4>
<p>Hmm.</p>



<a name="245465789"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/146212-t-compiler/const-eval/topic/NaNs%20during%20CTFE/near/245465789" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> RalfJ <a href="https://rust-lang.github.io/zulip_archive/stream/146212-t-compiler/const-eval/topic/NaNs.20during.20CTFE.html#245465789">(Jul 09 2021 at 16:34)</a>:</h4>
<p><span class="user-mention silent" data-user-id="229517">Jacob Lifshay</span> <a href="#narrow/stream/146212-t-compiler.2Fconst-eval/topic/NaNs.20during.20CTFE/near/245151702">said</a>:</p>
<blockquote>
<p>hmm, seems like bypassing <code>to_bits</code> can be done by using <code>transmute</code> or <code>union</code>, would those errors also occur in those cases?</p>
</blockquote>
<p>yes, if we follow the scheme of treating NaNs like we treat points, then transmuting would lead to errors</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>